-17- 



Application No. 09/273,238 
Docket No. 812495-150/10.230 



REMARKS 

The above amendment with the following remarks is submitted to be fully 
responsive to the Office Action of November 20, 2002. Reconsideration of this 
application in light of the amendment and the allowance of this application are respectfully 
requested. 

Claims 1-80 were pending in the present application prior to the above amendment. 
In response to the Office Action, claims 1, 11, 13, 15, 28, 32, 41, and 68 are amended to 
correct clerical errors and to more clearly claim the invention. Therefore, claims 1-80 are 
now pending in the present application and are believed to be in proper condition for 
allowance. 

Initially, Applicants note that the Office did not reject claims 1-5 and has included 
the standard paragraph regarding allowable subject matter. Applicants presume that the 
Office has allowed claims 1-5. If claims 1-5 are not allowed, Applicants respectfully 
request the Office state the rejection more clearly. 

112 rejection 

Referring now to the Office Action, claim 1-16 are rejected under 35 U.S.C. 112, 
first paragraph, as containing subject matter which was not described in the specification 
in such a way as to enable one skilled in the art to which it pertains, or with which it is 
most nearly connected, to make and/or use the invention. 

Applicant notes that the "split transaction" of claims 1-16 is described in the 
specification on pages 60-64. The "split transaction" referred thereto is the transaction 
between a bus coupled to a device over a network, that is, a transaction split between the 
device and bus by the network, where the bus and device would normally be located 
immediately adjacent each other with no latency or delay. In the specification, a "split 
transaction" is described as follows: 
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Most asynchronous IEEE- 13 94 transactions from a 
particular device are serialized in order to guarantee order 
of delivery and because IEEE-1394 is a bus, not a network 
(so transaction and wire delays are not an issue). This may 
cause problems when tunneling because the latencies 
involved in confirmation of an individual packet or 
completion of a split transaction across a network are very 
large. (Specification, p. 60, lines 16-22.) 

Claim 1 is rejected for lack of antecedent basis in the limitations "a bus device" 
and "the device". Applicants have replaced "a device" in the preamble with "a bus 
device"; "a bus device" with "the bus device"; and "the device" with "the bus device". 
Claims 11, 13, and 15 are rejected for a clause that is unclear in meaning. Applicants have 
replaced "posting the write request on the interface by completing a split transaction 
immediately via a response generated by software and not placing the split transaction 
over the network and then sending the write request over the network" with "generating a 
write response to the write request before sending the write request to a network host." By 
the amendments made, Applicants believe these rejections are now overcome. 

Rejections under Xu 

Claims 11-17, 19, 21-23, 26-29, 31-32, 34-36, and 39-41 are rejected under 35 
U.S.C. 102(e) as being anticipated by Xu et al., U.S. Patent No. 6,151,628 (Xu). 

The Office states that Xu "discloses a method for connecting a source of digital 
data to a computer network in which a tunneling call acceptance procedure is taught." The 
Office further states that "Xu specifically teaches a write request (incoming call 100 and 
the access request 102), acknowledge complete (call accept), encapsulating the write 
request into packets with tunneling header (incoming call request with dialing number of 
the remote user, the telephone number dialed, and a subaddress 106), transmitting the 
packets over the network (IP packet transfer 128), and receiving a response that write 
request data has been delivered to a network host (access reply 104)". Applicants 
respectfully disagree. 

Xu does not disclose or suggest "generating a write response to the write request 
before sending the write request to a network host" as recited in claim 1 1 , "means for 
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receiving a write request from the device and generating a write response to the write 
request before sending the write request to a network host" as recited in claim 13, or 
"generating a write response to the write request before sending the write request to a 
network host" as recited in claim 15. 

Xu does not disclose or suggest "the interface generating an acknowledge complete 
indication to indicate to the serial bus device that the transaction is complete" as recited in 
claim 17, "means for generating an acknowledge complete indication to indicate to the 
serial bus device that the transaction is complete" as recited in claim 23, or "generating an 
acknowledge complete indication to indicate to the serial bus device that the transaction is 
complete" as recited in claim 28. 

Xu does not disclose or suggest "the interface immediately sending a serial bus 
write response to the serial bus device indicating that the transaction has been completed" 
as recited in claim 29, "means for immediately sending a serial bus write response to the 
serial bus device indicating that the transaction has been completed" as recited in claim 36, 
or "immediately sending a serial bus write response to the serial bus device indicating that 
the transaction has been completed" as recited in claim 41. 

The Office's attention is respectfully directed to Figs. 6, 7, 10, and 1 1 in Xu which 
illustrate a telephone network that transmits a call accept upon receiving an access request 
for an incoming call. In Xu, a call is placed with several steps, where the process starts 
with an incoming call at step 100 (col. 11, lines 20-25). Next, at step 102, a first phase 
authorization routine with an authentication server is initiated (col. 11, lines 26-29). At 
step 104, the authentication server issues an Access-Reply message (col. 11, lines 41-48). 
At step 106, an Incoming-Call-Request message is sent to the tunneling server, and then, 
at step 108, an Incoming-Call-Reply message is sent, such as Connect if the result of the 
access inquiry is affirmative (col. 11, lines 50-57). At step 1 10, if the Connect message 
was received from the tunneling server, a call accept message is sent to the remote user, 
and an incoming call connect message is then relayed at step 1 12 to the tunneling server 
(col. 1 1 , lines 59-64). It is possible that during the access authorization, the authentication 
server determines that the remote user is not authorized to access the designated network 
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served by the authentication server (col. 12, lines 26-32). When the authentication server 
determines that the remote user is not authorized, an Access-Reject message is sent from 
the authentication server (col. 12, lines 35-38). 

The Office has compared Xu's call accept with Applicant's acknowledge complete 
indication. More specifically, the Office has compared Xu's call accept with "generating a 
write response to the write request before sending the write request to a network host", as 
is recited in claims 11, 13, and 15; with "generating an acknowledge complete indication 
to indicate to the serial bus device that the transaction is complete" as is recited in claims 
17, 23, and 28; and with "immediately sending a serial bus write response to the serial bus 
device indicating that the transaction has been completed" as is recited in claims 29, 36 
and 41. 

However, Xu's call accept is a preliminary indication to the user that the user has 
passed a preliminary security point and is authorized to use the network. The call accept 
message is sent to a remote user following an initial access inquiry, and allows the remote 
user to continue to access the network (col. 11, lines 59-64). 

In Applicant's "generating a write response to the write request before sending the 
write request to a network host", as is recited in claims 11, 13, and 15, the write response 
does not correspond to Xu's initial indication of authorization. Instead, the write response 
is generated, in the present invention, at a time before it would be generated by the bus 
device in an ordinary write process. In the present invention, the write response is 
generated before sending the write request to a network host, out of the ordinary order of a 
write process. In Applicant's "generating an acknowledge complete indication to indicate 
to the serial bus device that the transaction is complete" as is recited in claims 17, 23, and 
28, the acknowledge complete indication does not correspond to Xu's initial indication of 
authorization. Instead, the acknowledge complete indication is generated, in the present 
invention, before sending the write request to the serial bus device . In an ordinary write 
process, the serial bus device only receives an indication that the transaction is complete at 
the end of a transaction, rather than before the end of the transaction, as in the present 
invention. In Applicant's "immediately sending a serial bus write response to the serial 
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bus device indicating that the transaction has been completed" as is recited in claims 29, 
36 and 41, the serial bus write response does not correspond to Xu's initial indication of 
authorization. Instead, the serial bus write response is generated, in the present invention, 
before sending the write request to the network host , out of the ordinary order of a write 
process. 

Similarly, the Office has compared Xu's access reply 104 with Applicant's 
receiving a response that write request data has been delivered to the network host. 
However, Xu's access reply 104 is merely an initial response from the authentication 
server that the user is authorized to access the network. The authentication server issues 
an Access-Reply message 104 upon receiving an incoming call, and then an Incoming- 
Call-Request message is sent to the tunneling server (col. 1 1, lines 20-57). 

In Applicant's "receiving a response that write request data has been delivered to 
the network host", as is recited in claims 11, 13, 15, 17, 23, 38, 29, 36 and 41, the 
receiving step does not correspond to Xu's access reply 104. Instead, the receiving step is 
a final step where the interface receives a response similar to the write response or 
acknowledge complete indication that was previously generated and sent to the interface. 
This receiving step is an actual confirmation that the write request was received by the 
network host. Thus, Applicant's claimed invention allows a bus device to send a write 
request, receive a write request of acknowledge complete indication immediately, and then 
the write request is sent across the network to the network host, thereby allowing the 
device to continue to send data without waiting for the final confirmation indicating that 
the transaction is complete. 

Because Xu does not teach each and every limitation of claims 11-17, 19, 21-23, 
26-29, 31-32, 34-36, and 39-41, specifically, sending a write response or acknowledge 
complete response indicating that the entire transaction is complete, before the transaction 
is complete, thereby allowing the device to continue to send data without waiting for the 
final confirmation indicating that the transaction is complete, Applicants respectfully 
submit that Xu does not anticipate claims 1 1-17, 19, 21-23, 26-29, 31-32, 34-36, and 39- 
41 . Accordingly, in view of the foregoing remarks, the Office is respectfully requested to 
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reconsider and withdraw the rejections of claims 1 1-17, 19, 21-23, 26-29, 31-32, 34-36, 
and 39-41. 

The Office has rejected claims 1 8, 20, 24-25, 30, 33, 37, and 38 are rejected under 
35 U.S.C. 103(a) as being unpatentable over Xu in view of Gerszberg et al., U.S. Patent 
No. 6,480,748 (Gerszberg). The Office acknowledges that "Xu fails to teach IEEE 1394 
devices". The Office then states that "Gerszberg teaches IEEE 1394 bus and devices used 
in conjunction with tunneling scheme used in access network. See Figs. 2, 5, 9, 14, and 
15." The Office then asserts that "[i]t would have been obvious for one of ordinary skill in 
the art at the time of the invention to implement the teaching of Xu by adopting the IEEE 
1394 devices as taught by Gerszberg since it was known to use IEEE device and bus for 
connecting to a network using tunneling scheme". 

As above, Applicants respectfully submit that Xu does not teach, disclose or 
suggest each and every limitation of independent claims 17, 23, 29, and 36, from which 
dependent claims 18, 20, 24-25, 30, 33, 37, and 38 depend, specifically, sending a write 
response or acknowledge complete response indicating that the entire transaction is 
complete, before the transaction is complete, or receiving a response that write request 
data has been delivered to the network host. 

Additionally, Applicants respectfully submit that Gerszberg also does not teach, 
disclose or suggest a write response or acknowledge complete indication indicating that 
the entire transaction is complete, before the transaction is complete, or receiving a 
response that write request data has been delivered to the network host, as is disclosed in 
independent claims 17, 23, 29, and 36, from which dependent claims 18, 20, 24-25, 30, 33, 
37, and 38 depend. 

The Office's attention is respectfully directed to Figs. 1A-1E, 2, and 6A-6B in 
Gerszberg, disclosing a voice and data network. The system of Gerszberg is directed to 
optimizing and increasing bandwidth in a voice and data network (see SUMMARY 
section). Gerszberg uses a telephone network including DSL, combined with data 
protocols including PPTP, firewire and USB, to optimize bandwidth in a high-volume 
traffic network. Gerszberg does not teach receiving a write response or acknowledge 
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complete indication generated by the interface, and does not teach receiving a response 
that write request data has been delivered to the network host, as is disclosed in 
independent claims 17, 23, 29, and 36, from which dependent claims 18, 20, 24-25, 30, 33, 
37, and 38. 

Because neither Xu nor Gerszberg teach, disclose or suggest a write response or 
acknowledge complete indication, or receiving a response that write request data has been 
delivered to the network host, as is disclosed in independent claims 17, 23, 29, and 36, 
from which dependent claims 18, 20, 24-25, 30, 33, 37, and 38; no combination of Xu and 
Gerszberg would have taught or suggested each and every limitation of claims 18, 20, 24- 
25, 30, 33, 37, and 38. Thus, Applicants respectfully submit that neither Xu nor 
Gerszberg, alone or in combination, renders claims 18, 20, 24-25, 30, 33, 37, and 38 
unpatentable. Accordingly, in view of the foregoing remarks, the Office is respectfully 
requested to reconsider and withdraw the rejections of claims 18, 20, 24-25, 30, 33, 37, 
and 38. 

Rejections under Chau 

Claims 6, 7, 9, 10, 42, 45-49, 51-60, 62-72, 74-75, and 77-80 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Chau et al., U.S. Patent No. 6,233,232 (Chau). 
The Office states that "Chau discloses architecture for connecting a plurality of telephone 
lines to a computer network. Specifically, Chau teaches a network (130), a bus (140, 142, 
144), a bus device coupled to the bus (computer system 150, 152, 154), an interface 
(network access server 100, 110, 120) coupling the network to the bus, the interface 
tunneling bus events over the network to and from the bus device by encapsulating bus 
events generated by the bus device into packets and transferring the encapsulated bus 
events over the network for subsequent decapsulation to recreate the bus events. See col. 
6, line 48-54, and col. 7, lines 47-49." The Office additionally states that "Chau fails to 
specifically teach sending an announcement packet over the network that encapsulates bus 
event corresponding to a bus reconfiguration process for the bus. However, Chau teaches 
establishing multilink connections through multiple network access servers. This process 
involves receiving request for multilink connection and allocating logical and physical 
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ports for connections establishment. See Fig. 13 and col. 13, lines 16-34. This process is 
a configuration in logical sense. Therefore, it would have been obvious for one of 
ordinary skill in the art at the time of the invention to implement the connection 
establishment of Chau by sending bus configuration command. The Office further states 
that Chau "fails to teach a Universal Serial Bus (USB) device coupled to the bus. USB 
device is well known in the field of the invention as recognized by applicant in the present 
specification page 3. It refers to a device conforming to the Universal Serial Bus 
Standard. Therefore, it would have been obvious for one of ordinary skill in the art at the 
time of the invention to implement Chau's system by specifically utilizing USB device as 
the bus device." 

The Office's attention is respectfully directed to Figs. 1, 13, 14, 15, and 16 in 
Chau, disclosing a voice and data network. Chau is directed to a flexible telephone and 
data network that can be changed to accommodate different needs (see SUMMARY 
section). In Chau, multiple lines can be added while preserving a single system image, 
allowing bandwidth-on-demand by setting up and tearing down telephone lines as needed. 
Chau generally describes receiving information, packetizing the information, and sending 
the packets across the Internet (see col. 6, line 48- col. 7, line 50). However, Chau does 
not describe sending an indication or response that a transaction has been completed; 
capturing a bus event corresponding to a bus reconfiguration process and tunneling the bus 
event across a network; tunneling URB requests that are based on the captured bus events 
over the network; an interface buffering isochronous data to manage network latencies 
over the asynchronous network; using a data confirmation packet to determine whether to 
continue sending isochronous data; or encapsulating an ownership tunneling packet to 
manage network ownership of a bus device. 

With respect to claims 6-7 and 9-10, which recite "sending an indication or 
response to the bus device that the transaction has been completed, and then encapsulating 
bus events generated by the bus device into packets and transferring the packets over the 
network", Applicants respectfully submit that Chau only generally refers to packetizing 
the information (col. 6, line 48- col. 7, line 50). There is no teaching or suggestion in 
Chau describing sending an indication or response that a transaction has been completed, 
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and then encapsulating bus events from the bus device into packets and sending them over 
the network. 

With respect to claims 42, 45-49, and 51-54, which recite "the interface tunneling 
bus events over the network to and from the bus device by encapsulating bus events 
generated by the bus device into packets and transferring the encapsulated bus events over 
the network for subsequent decapsulation to recreate the bus events, and further wherein 
the interface sends an announcement packet over the network that encapsulates bus events 
corresponding to a bus reconfiguration process for the bus" and "capturing bus events 
corresponding to a bus configuration process generated on a bus; encapsulating the 
captured bus events into at least one packet associated with a network protocol using an 
interface; sending the at least one packet over the network so that the capsulated bus event 
may be decapsulated to recreate the bus events at a remote site" , Applicants respectfully 
submit that Chau only refers to allocating logical and physical ports upon a request (col. 
13, lines 13-64). The Office states that "Chau teaches establishing multilink connections 
through multiple network access servers. This process involves receiving request for 
multilink connection and allocating logical and physical ports for connections 
establishment." The Office concludes that "[t]his process is a configuration in logical 
sense." However, Applicants respectfully submit that the multilink establishment of Chau 
is dissimilar from capturing a bus event corresponding to a bus reconfiguration process 
and tunneling the bus event across a network, as is disclosed in claims 42, 45-49, and 51- 
54. In the multilink establishment of Chau, the system receives a request for a multilink 
establishment, and then allocates physical ports to accommodate the request (col. 13, lines 
16-34). However, the bus reconfiguration event of claims 42, 45-49, and 51-54 sends 
information about a bus reconfiguration event across the network in packet form, rather 
than requesting establishment of a multilink, as in Chau. 

With respect to claims 55-57, the claims recite "the interface tunneling URB 
requests over the network to and from the bus device by encapsulating the URB requests 
into network protocols and transferring the encapsulated the URB requests over the 
network for subsequent decapsulation to recreate USB bus events" and "capturing bus 
events generated on a bus; encapsulating URB requests that are based on the captured bus 
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events into packets associated with a network protocol using an interface; and sending the 
encapsulated bus events for subsequent decapsulation at a remote site". Applicants 
respectfully submit that Chau only generally refers to packetizing the information (col. 6, 
line 48- col. 7, line 50). Chau does not teach tunneling URB requests that are based on the 
captured bus events over the network to and from the bus device. 

With respect to claims58-60 and 62-65, the claims recite "an asynchronous 
network; a bus; a bus device coupled to the bus, wherein the bus device generates 
isochronous data; an interface coupling the network to the bus, the interface tunneling bus 
events over the network by encapsulating bus events into network protocols, transferring 
the encapsulated bus events over the network, and subsequently decapsulating the bus 
events to recreate the bus events, and further wherein the interface buffers isochronous 
data to manage network latencies". Claim 66 recites "capturing bus events; encapsulating 
the captured bus events into packets associated with a network protocol; and an interface 
decapsulating the capsulated bus event and recreating them at a remote site, including 
buffering isochronous data to manage network latencies". Applicants respectfully submit 
that Chau only generally refers to packetizing the information (col. 6, line 48- col. 7, line 
50). Chau does not teach an interface tunneling bus events over the network by 
encapsulating bus events into network protocols such that the interface buffers 
isochronous data to manage network latencies over the asynchronous network. Similarly, 
Chau does not teach encapsulating the captured bus events into packets and buffering 
isochronous data to manage network latencies. 

With respect to claims 67-68, the claims recite "the interface sending a data 
confirmation packet over the network after transmission of the bus events on a bus 
coupled to the interface; and the network host processing the data confirmation packet and 
determining whether to continue sending isochronous data" and "the interface and host 
coordinating to tunnel bus events over the network between the host and the bus device by 
encapsulating bus events into network protocols, transferring the encapsulated bus events 
over the network, and subsequently decapsulating the bus events to recreate the bus 
events, wherein the interface sends a data confirmation packet to the host after 
transmission on the bus of bus events representing isochronous data tunneled over the 
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network from the host, the host receiving the data confirmation packet and, based on its 
contents, determines whether to continue sending isochronous data". Applicants 
respectfully submit that Chau only generally refers to packetizing the information (col. 6, 
line 48- col. 7, line 50). Chau does not teach an interface sending a data confirmation 
packet after transmission of bus events, and using the data confirmation packet to 
determine whether to continue sending isochronous data. 

With respect to claims 69-72, 74-75, and 77-80, the claims recite "encapsulating 
the captured bus events into packets associated with a network protocol, where at least one 
of the packets comprises an ownership tunneling packet to manage network ownership of 
a bus device" and "means for encapsulating the captured bus events into packets 
associated with a network protocol using an interface, where at least one of the packets 
comprises an ownership tunneling packet to manage network ownership of a bus device". 
Applicants respectfully submit that Chau only generally refers to packetizing the 
information (col. 6, line 48- col. 7, line 50). Chau does not teach encapsulating the 
captured bus events into packets associated with a network protocol using an interface, 
where at least one of the packets comprises an ownership tunneling packet to manage 
network ownership of a bus device. 

Because Chau does not teach, disclose or suggest each and every element of claims 
6-7, 9-10, 42, 45-49, 51-60, 62-72, 74-75, and 77-80, Applicants respectfully submit that 
Chau does not render claims 6-7, 9-10, 42, 45-49, 51-60, 62-72, 74-75, and 77-80 
unpatentable. Accordingly, in view of the foregoing remarks, the Office is respectfully 
requested to reconsider and withdraw the rejections of claims 6-7, 9-10, 42, 45-49, 51-60, 
62-72, 74-75, and 77-80. 

Claims 8, 44, 50, 61, 73, and 76 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Chau in view of Gerszberg. The Office states that "Chau fails to 
specifically teach IEEE 1394 bus. Gerszberg teaches IEEE 1394 bus and devices used in 
conjunction with tunneling scheme used in access network. See Figs. 2, 5, 9, 14 and 15. 
It would have been obvious for one of ordinary skill in the art at the time of the invention 
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to implement the teaching of Chau by adopting IEEE 1 394 devices of Gerszberg since it is 
well known in Gerszberg to utilize IEEE 1394 devices in tunneling scheme. 

As argued above, neither Chau nor Gerszberg teach or suggest each and every 
element of the independent claims 6, 42, 48, 58, 69, or 76, from which claims 8, 44, 50, 
61, 73, and 76 depend. Because neither Chau nor Gerszberg teach, disclose or suggest 
each and every element of claims 8, 44, 50, 61, 73, and 76; no combination of Chau and 
Gerszberg would have taught or suggested each and every limitation of claims 8, 44, 50, 
61, 73, and 76. Thus, Applicants respectfully submit that neither Chau nor Gerszberg, 
alone or in combination, renders claims 8, 44, 50, 61, 73, and 76 unpatentable. 
Accordingly, in view of the foregoing remarks, the Office is respectfully requested to 
reconsider and withdraw the rejections of claims 8, 44, 50, 61, 73, and 76. 



In view of the foregoing, it is submitted that the present application is in condition 
for allowance and a notice to that effect is respectfully requested. However, if any issue 
remains after considering this response, the Office is invited to call the undersigned to 
expedite the prosecution and work out any such issue by telephone. 



NIXON PEABODY LLP 
401 9th Street, N.W., Suite 900 
Washington, D.C. 20004-2128 
(202) 585-8000 
(202) 585-8080 (Fax) 
Customer No. 22204 

Dated: July 20, 2007 



Conclusion 



Respectfully submitted, 
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